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The  widening  of  the  battlefield  and  decrease  in  the  density 
of  combatants  have  made  it  more  and  more  difficult  for  the 
commander  to  /-"sense”7  the  location  and  condition  of  his  forces. 
Technological  developments  have  increased  the  pace  and  fluidity 
of  combat;  and  reduced  the  time  available  for  sensing  the 
situation,  evaluating  the  situation,  and  taking  actions  necessary 
to  thwart  the  enemy  intentions  and  win  the  battle.  The  commander 
must  "see”  the  wider  battlefield,  "sense"  the  enemy's  intention, 
and  plan,  direct  and  coordinate  actions  to  defeat  the  enemy  in 
the  close,  deep  and  rear  Airland  Battles.  Automated  Command  and 
Control  Systems  need  to  capitalize  on  the  same  technology  that 
widened  the  battlefield  to  provide  the  information  necessary  to 
"see"  and  "sense"  without  overwhelming  information  and  provide  a 
means  to  rapidly  communicate  the  information  necessary  to  carry 
out  the  commanders  intention.  This  paper  describes  the  switch 
from  the  revolutionary  to  the  evolutionary  approach  to  design  of 
a  command  and  control  system,  the  proposed  fielding  program  for 
the  Maneuver  Control  System,  and  command  and  control  initiative 
within  the  United  States  Army  Europe.  There  have  been  many 
initiatives,  formal  and  informal,  to  develop  such  a  command  and 
control  system.  Informal  initiatives  need  to  continue  to  place 
systems  in  the  field  now  and  provide  user  input  to  insure  that  an 
effective  Maneuver  Control  System  is  fielded  for  use  throughout 
the  Army. 


COMMAND  AND  CONTROL  ARCHITECTURE  OF  THE  FUTURE 


Command  and  control  has  always  been  vitally  important  in 
the  management  of  crisis  and  the  employment  of  military  power, 
and  it  has  never  been  more  important  than  now.  If  a  command  is 
to  function  as  a  coherent  body,  its  command  and  control  nervous 
system,  and  especially  the  displays  which  form  the  critical 
interfaces  between  these  systems  and  decision  makers  they  serve 
must  be  the  best  that  we  know  how  to  provide.  However,  simply 
knowing  about  new  techniques  is  not  enough.  Before  the  new 
techniques  can  be  applied,  there  must  be  a  thorough  understanding 
of  the  operational  requirements  to  be  met.  The  fact  that  the 
potential  of  modern  display  technology  and  automatic  data 
processing  has  not  yet  been  fully  exploited  is  not  because  there 
is  a  technical  gap,  but  an  application  gap  in  bringing  our 
technical  know-how  to  bear  on  our  vital  requirements. 

There  appear  to  be  three  main  reasons  for  this.  First,  our 
analysis  of  requirements  have  not  been  specific  enough;  second, 
we  have  failed  to  pinpoint  which  requirements  are  most  vital;  and 
third,  we  have  not  translated  our  requirements  into  feasible 
system  concepts.  We  have  been  long  on  generalized  statements 
about  the  need  for  better  data  processing  systems  and  displays, 
but  short  on  specific  concepts  of  how  they  can  help  solve 
particular  command  and  control  problems.  To  close  the 
application  gap,  we  need  to  bring  our  requirements  into  sharper 
focus,  to  move  from  the  general  to  the  particular,  from  the 


abstract  to  the  concrete. 


At  the  same  time  we  need  to  develop  a  wider  perspective  on 
the  nature  of  the  command  and  control  process  so  that  we  can  see 
more  clearly  which  display  applications  are  most  likely  to  be 
most  vital  and  therefore  likely  to  make  the  most  substantial 
contributions  to  our  command  and  control  capabilities. 

The  purpose  of  this  paper  is  to  illustrate  how  we  can 
achieve  focus  and  perspective  in  developing  command  and  control 
requirements.  It  is  not  a  comprehensive  statement  of  all  the 
requirements  that  exist;  however,  by  illustrating  the  initiatives 
within  the  United  States  Army  Europe  (USAREUR)  and  the  approach 
to  developing  the  Engineer  Command  and  Control  System  (ECCS) 
architecture,  it  may  help  to  indicate  some  of  the  directions  we 
need  to  go. 

I  will  not  take  time  here  to  develop  another  definition  of 
command  and  control  to  add  to  those  already  in  existence.  We  may 
have  already  spent  too  much  time  trying  to  define  terms  and  too 
little  trying  to  understand  what  the  terms  mean,  and  may  have  got 
on  the  wrong  track  altogether  in  trying  to  describe  command  and 
control  in  terms  of  facilities,  personnel  and  procedures. 

Command  and  control  is  none  of  these,  though  it  involves  all  of 
them.  It  is  rather  a  set  of  related  processes  which  help  a 
decision  maker  perceive  what  is  happening,  decide  what  to  do,  and 
control  weapons  and  forces  so  as  to  implement  the  desired 
strategies. 


Each  of  the  three  basic  processes  -  perceiving,  decision 
planning  and  controlling  -  depends,  in  turn,  on  the  effective 
performance  of  two  specific  command  and  control  functions.  The 
process  of  perception  involves  (1)  situation  reporting  and  (2) 
resource  reporting.  The  process  of  decision  planning  involves 
(1)  the  evaluation  of  alternative  courses  of  action  and  (2) 
consultation  between  decision  makers  and  their  staffs  to  compare 
plans  and  coordinate  actions.  The  process  of  controlling 
involves  (1)  directing  the  actions  of  weapons  and  forces  and  (2) 
defining  the  necessary  restraints  on  their  actions. 

All  six  of  these  vital  functions  have  to  be  carried  out 
continuously,  in  greater  or  less  detail,  and  with  greater  or  less 
urgency,  at  all  levels  of  military  and  political  decision  making, 
under  a  wide  range  of  crisis  and  conflict  situations  from  low 
levels  of  conflict  to  all  out  nuclear  war. 

They  are  vital  because  they  directly  support  decision 
makers  and  their  staffs  as  they  deal  with  crisis  and  conflicts, 
agree  on  the  strategy  too  be  followed,  and  take  the  actions 
required  to  implement  it.  They  do  not,  of  course,  guarantee 
effective  decision  making  or  ensure  the  success  of  the  strategy. 
But  sound  decisions  and  successful  strategies  are  likely  to  be 
impossible  unless  these  functions  are  carried  out  effectively.1 

There  are  two  levels  where  decisions  are  made:  the  tactical 
level  and  the  division  or  higher  level.  The  tactical  level  is  up 
through  brigade  where  the  battle  is.  At  this  level,  decisions 
are  made  on  the  spot  and  are  made  based  on  direct  observations. 
These  observations  can  lead  to  actions  on  the  part  of  commanders 


who  are  in  the  position  to  see  the  actual  combat  or  to  move 
quickly  to  a  position  where  they  can  see.  At  division  or  higher 
levels,  commanders  can  see  only  pieces  of  the  battle.  The 
decisions  made  by  these  commanders  do  not  have  an  immediate 
effect  on  the  battle.  At  each  echelon,  moving  up  from  the 
division,  the  time  line  between  decisions  and  actions  increase  in 
length. 

The  principal  decisions  at  these  higher  echelons  normally 
involve  moving  units  and  allocating  resources.  Since  it  takes  48 
hours  to  properly  commit  a  division,  a  major  task  should  be  to 
forecast  the  situation  48  -  96  hours  in  the  future.  Thus  there 
is  a  clear  need  for  automatic  data  processing  and  simulation  in 
support  of  the  forecasting  operations. 

We  can  get  an  intuitive  idea  of  which  functions  are  likely 
to  require  and  benefit  from  modern  display  and  information 
processing  techniques.  Clearly,  the  two  "seeing"  functions;  the 
perception  of  the  current  military  situation  and  the  availability 
of  military  resources  head  the  list.  To  perform  their  mission, 
decision  makers  and  their  staffs  must  have  timely  and  accurate 
information  on  the  current  ground  and  air  situation  and  the 
forces  and  weapons  that  are  or  may  be  available.  This 
information  provides  the  basis  for  all  subsequent  planning, 
weighing  of  alternative  strategies,  decision  making  and  action. 

As  already  suggested,  there  are  likely  to  be  significant 
changes  in  the  relative  emphasis  on  various  functional  and 
performance  requirements  as  we  move  across  the  spectrum  of 
conflict.  The  basic  command  and  control  processes  and  the  vital 


functions  which  support  them  do  not  change;  but  the  level  of 
effective  decision,  the  amount  and  kind  of  information  needed  at 
various  levels,  and  its  required  timeliness  and  accuracy  are 
likely  to  vary  depending  on  the  kind  of  crisis  and  conflicts  that 
are  envisioned  and  the  strategies  that  are  planned. 

Despite  the  most  careful  advanced  planning,  the  exact 
circumstances  and  timing  of  the  events  which  might  trigger  the 
decision  process  cannot  be  foreseen.  All  we  can  be  certain  of  is 
that  when  the  time  comes  for  decisions  to  be  made,  they  are 
likely  to  be  needed  quickly.  There  will  probably  not  be  enough 
time  for  the  slow,  sequential  processing  of  information  and 
decision  planning  at  each  echelon  of  command  in  turn.  Instead, 
all  echelons  of  command  will  need  to  work  essentially  in 
parallel . 

At  such  times,  the  overriding  requirement  is  likely  too  be 
for  timely  and  accurate  information  on  the  current  military 
situation.  The  decision  makers  and  staffs  at  all  levels  of 
command  will  want  to  know  what  is  happening  where  the  fighting  is 
going  on  and  will  want  this  information  just  as  fast  as  they  can 
possibly  get  it. 

This  desire  for  timely  and  accurate  situation  information 
at  higher  military  and  political  decision  levels  does  not  imply  a 
lack  of  trust  in  lower  echelon  commanders  or  a  desire  to 
interfere  with  their  decisions.  On  the  contrary,  if  higher  level 
decision  makers  use  the  information  wisely,  they  will  use  it  for 
enlarging  the  lower  level  commanders'  freedom  of  action,  by 
getting  ready  to  make  the  required  political-military  decisions 
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promptly  when  they  are  needed.  They  are  likely  to  be  in  a 
position  to  do  this  only  if  they  are  following  the  developing 
situation  closely,  continually  evaluating  alternative  courses  of 
action,  and  trying  to  anticipate  possible  decision  points. 

Failure  to  provide  adequate  information  for  this  purpose 
results  in  less,  not  more,  freedom  of  action  for  lower  echelon 
commanders.  Their  ability  to  act  is  necessarily  restricted 
during  the  interval  that  it  takes  higher  level  decision  makers 
and  their  staffs  to  gather  information  that  they  consider 
essential,  evaluate  the  situation,  and  reach  a  decision.  It  is 
therefore  as  much  in  the  interest  of  lower  echelon  commanders  and 
their  staffs  to  provide  timely,  accurate  situation  information  as 
it  is  in  the  interest  of  higher  decision  makers  and  their  staffs 
to  process,  display,  and  use  it  effectively.  This  is  the  best, 
and  perhaps  the  only,  means  of  trying  to  ensure  that  when  higher- 
level  decisions  are  needed,  they  will  be  timely,  sound  and 
relevant. 

If  we  were  designing  a  command  and  control  system  from  the 
ground  up,  we  would  therefore  have  to  think  not  only  of  all  the 
functional  and  performance  requirements  to  be  met,  but  of  all  the 
possible  crisis  and  conflict  situations  under  which  these 
functions  might  have  to  be  carried  out.  In  practice  the  task  is 
rarely  this  comprehensive.  We  almost  always  start  with  some 
existing  or  planned  capabilities,  we  usually  have  some  idea  of 
the  kinds  of  situations  that  are  likely  to  occur,  and  we  have 
usually  developed  some  plans  and  strategies  that  we  may  want  to 
implement.  The  task  thus  becomes  one  of  evaluating  the 
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capabilities  and  limitations  of  the  existing  and  programmed 
facilities,  identifying  specific  potential  capability  gaps  that 
appear  to  limit  the  feasibility  and  therefore  the  choice  of 
strategies,  and  seeing  how  these  deficiencies  can  be  remedied. 

This  historical  "broad  systems  approach"  to  the  development 
of  command  and  control  systems  cannot  resolve  the  fundamental 
difficulties  of  obtaining  valid  user  functional  requirements. 
Futhermore,  the  local  development  of  command  and  control  systems 
relying  entirely  upon  the  capabilities  of  the  user  command,  the 
"bits  and  pieces"  approach  is  found  to  be  wanting  and  tends  to 
produce  costly  and  repetitive  trial  and  error  cycles.  An 
alternative  evolutionary  approach  which  would  ensure  that  the 
valuable  military  service  hardware  and  software  expertise  will  be 
made  available  to  any  and  all  military  users  in  an  appropriate 
manner  is  required.  This  approach  preserves,  maintains  and 
disseminates  the  useful  and  established  knowledge  and  experience 
gained  from  military  command  and  control  development  efforts.  It 
recognizes  the  need  to  assign  greater  responsibility  to  user 
commands  for  the  development  of  their  own  command  and  control 
systems,  while  at  the  same  time  providing  for  such  commands  a 
means  of  obtaining  greater  capabilities  in  this  area. 

The  approach  that  attempts  to  stipulate  several  years  in 
advance  what  the  initial  operational  capability  of  a  given 
command  and  control  system  should  be  "the  broad  systems  approach" 
has  lately  tended  to  be  discarded  in  favor  of  one  involving 
gradual  evolution.  Futhermore,  it  is  now  recognized  that  command 
and  control  systems  must  evolve  within  the  context  of 


the  user  command. 


Historically,  the  attempts  to  resolve  the  basic 
difficulties  in  obtaining  operational  requirements  for  command 
and  control  systems  led  to  the  creation  of  special  agencies 
within  the  military  services  and  Department  of  Defense.  The 
over-all  management  responsibility  for  the  development, 
acquisition,  and  delivery  of  command  and  control  systems  was 
located  in  such  agencies.  In  general,  the  eventual  system  user 
had  representatives  in  the  appropriate  agency  and  was  thereby 
enabled  to  participate  in  the  system  design  phase.  In  this 
manner,  the  system  user  could  introduce  up-dated  functional 
requirements  that  often  resulted  in  program  design  changes. 
However,  compromise  was  inevitable.  In  order  that  the 
established  delivery  schedules  might  be  met,  great  pressure  was 
applied  to  freeze  the  system  design  early  so  that  hardware 
procurement  and  development  could  begin.  Soon  after  selection  of 
the  contractor  there  was  a  tendency  to  fix  upon  an  initial 
operational  capability,  reserving  changes  for  the  second  phase  of 
complete  operational  capability.  It  was  quickly  discovered  that 
most  aspects  of  the  system,  both  the  hardware  and  software,  soon 
became  cast  in  concrete.  At  this  point,  introduction  of  even 
relatively  small  program  design  changes,  however  important  these 
changes  might  be,  proved  costly  in  terms  of  both  funding  and 
delivery  time.  As  this  experience  became  the  common  pattern  in 
the  broad  systems  approach  to  command  and  control  developments, 
the  need  for  a  change  in  developmental  philosophy  became 
apparent. 
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The  recognition  of  the  necessity  for  an  evolutionary 
approach  to  the  development  of  improved  command  and  control 
capabilities  is  one  thing;  the  establishment  of  appropriate 
management  control  responsibilities  to  ensure  its  successful 
accomplishment  is  another.  How  "evolutionary  approach"  is 
interpreted  and  how  the  approach  is  put  into  effect  will 
significantly  contribute  to  the  success  or  failure  of  forthcoming 
command  and  control  systems.2 
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MANEUVER  CONTROL  SYSTEM 


MISSION 

MCS  IS  A  COMMAND  AND  CONTROL  (C2) 

SYSTEM  WHICH  PROVIDES  THE  ARMY 

MANEUVER  COMMANDER  AND  HIS  G3/S3 

AT  CORPS  ECHELONS  AND  BELOW  WITH 

AUTOMATED  ASSISTANCE  NEEDED  TO 

EXECUTE  PRECISE  REAL-TIME  COMMAND 

AND  CONTROL  OF  COMBAT  FORCES. 

FEATURES 

•  MCS  IS  BEING  BUILT  UNDER  AN 
EVOLUTIONARY  DEVELOPMENT 
PROGRAM  -  CONTINUOUS  FIELD 
USER  TESTING  AND  FEEDBACK 
DRIVE  SYSTEM  ENHANCEMENTS 

•  MCS  SOFTWARE  IS  BEING  IMPLE 
MENTED  IN  Ada 

•  MCS  NODES  COMMUNICATE  OVER 
STANDARD  ARMY  COMMUNICATIONS 

a  MCS  INTEGRATES  NON  OEVELOP 
MENT  ITEMS.  I  E..  COMMERCIALLY 
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The  Maneuver  Control  System  (MCS)  is  part  of  the  Army's 
tactical  command  and  control  system  delineated  as  the  Command  and 
Control  Subordinate  System  (CCS2)  architecture.  The  CCS 2 
architecture  was  developed  to  organize  and  simplify  the  analysis 
and  management  of  interoperability  requirements  for  Battlefield 
Automated  Systems  (BAS)  assigned  to  units  at  Corps  and  below, 
plus  to  improve  the  flow  of  information  on  the  battlefield.  It 
represents  the  Army’s  battlefield  command  and  control  system 
architecture.  The  CCS 2  architecture  subdivides  the  tactical 
command  and  control  systems  into  five  functional  segments.  The 
five  functional  segments  are:  Maneuver  Control,  Fire  Support, 
Intelligence  and  Electronic  Warfare,  Air  Defense  and  Combat 
Service  Support.  The  MSC  architecture,  approved  by  the  Army's 
Fifth  Battlefield  Automation  Appraisal  in  1980,  represents  the 
Army's  initiative  to  automate  primary  functions  of  maneuver 
control  under  the  direction  of  the  maneuver  force  commander. 

The  MSC  is  being  developed  through  the  evolutionary  process 
characterized  by  "Build  a  little  -  Test  a  little."  As  parts  of 
the  system  are  developed,  the  user  participates  in  tests  and 
evaluation.  Thus  valuable,  immediate  feedback  is  provided  and 
refinements  are  made  promptly.  In  addition,  as  user  needs  become 
more  clear,  MCS  development  adapts  to  meet  them.  The  fielding  of 
MCS  computer  hardware  and  software  capabilities  will  be  executed 
in  four  separate  blocks.  Each  block  will  build  on  the  hardware 
and  software  capabilities  in  the  previous  block  (Figure  2) . 

MCS  is  a  system  of  computer  equipment,  computer  software, 
communications  interface  devices,  facilities,  personnel  and 


Maneuver  Control  System  Implementation  Concept 


Hardware  Software 

***************************************************************** 


BLOCK  1  *  MCS  mil  spec:  *  MCS  version  9 

*  -Tactical  Computer  * 

4QFY86-  *  Terminal  (TCT)  * 

3QFY87  *  -Tactical  Computer  * 

*  Terminal  Prime  (TCT')  * 

*  * 

***************************************************************** 


BLOCK  2  *  MCS  mil  spec:  *  MCS  version  10 

*  -TCT  continue  * 

4QFY87-  *  -Load  Area  Network  (LAN)*  -MCS/DCCS  convergence 

3QFY88  *  *  -initial  graphics 

*  NDI:  *  -free  format  message 

*  -Tactical  Computer  * 

*  Processor  (TCP)  * 

*  -Analyst  Console  (AC)  * 

*  * 

★★★★★★★★★★★★TV**************************************************** 


BLOCK  3 


4QFY88-FY91 


*  NDI: 

*  -graphics  displays 


*  MCS  version  11 

*  -Force  level  control 

*  -MCS/MTF  lashup 

*  -enhanced  graphics 

*  -embedded  training 

*  programs 

*  -simulation  exercise 

*  -initial  artificial 

*  intelligence 


**************************************************************** 


BLOCK  4 


*  MCS  mil  spec: 


*  MCS  to  ACCS  transition 


*  -Battalion  Terminal  (BT)* 

early  90' s-  *  -MCS  to  ACCS  transition  * 

mid  90 's  *  -Refurbished  MCS  to  * 

*  Reserve  component  * 

*  * 

***************************************************************** 


Figure  2 


procedures.  It  provides  commanders  and  their  staffs  from 
Battalion  through  Division  with  an  automated  system  for  planning, 
directing,  and  controlling  operations.  MCS  is  designed  to 
support  sustained  combat  operations  in  all  levels  of  conflict,  to 
be  operational  24  hours  a  day,  and  to  be  deployable  worldwide. 

It  makes  maximum  use  of  commercial  off-the-shelf  hardware  and 
software  integrated  with  existing  Army  tactical  communications. 
This  approach  allows  MCS  to  rapidly  take  advantage  of  technical 
advances  in  commercial  equipment.  Software  is  a  mix  of 
commercial  packages  and  special  applications  necessitated  by  the 
military  environment.  Supplies  are  available  through  the 
computer  stores  worldwide  and  some  are  available  through  Army 
supply  systems. 

The  MCS  provides  features  that  will  greatly  enhance  Command 
and  Control  (C2) .  By  automating  the  processing  and  displaying 
of  information,  the  large  amount  of  data  that  is  gathered  from 
widely  separated  areas  can  be  handled  efficiently  through  the  use 
of  highly  visual,  user-friendly  displays.  These  displays  provide 
knowledge  of  the  current  situation,  available  resources  and 
readiness  status.  The  commander  and  staff  can  then  accurately 
evaluate  the  information,  rapidly  issue  orders  and  instructions, 
remotely  monitor  how  well  those  orders  and  instructions  are 
carried  out,  and  rapidly  alter  plans  as  require  by  the  changing 
situation.  A  primary  benefit  of  this  feature  is  the  ability  to 
work  quickly.  The  cycle  of  acquiring  information,  making 
decisions,  issuing  orders,  and  ensuring  actions  move  faster  than 
the  enemy's  command  and  control  system 


Another  feature  of  the  MCS  is  the  provision  of  reliable 
data  regardless  of  the  commander's  or  staffs  location.  As  the 
data  base  is  automatically  updated,  it  is  replicated  at  multiple 
locations.  This  feature  has  a  number  of  benefits.  MCS 
survivability  is  enhanced  by  placing  the  same  critical 
information  in  many  locations.  Thus,  the  Division  can  sustain 
significant  degradation  before  the  ability  to  command  and  control 
is  seriously  impaired.  Also,  the  commander  is  provided  with 
battlefield  mobility  in  that  the  same  information  is  available  in 
fourteen  locations.  In  addition,  the  replicated  data  base 
provides  all  subordinate  commanders  with  the  same  view  of  the 
battlefield. 

MCS  will  be  compatible  with  other  Army  force  modernization 
programs  such  as  the  Position  Locating  and  Reporting  System 
(PLRS) .  MCS  will  provide  the  necessary  interface  to  those 
programs,  will  allow  access  to  common  collateral-level  databases 
and  will  provide  the  means  to  move  data  throughout  the  Division. 

The  MCS  operates  to  insure  the  timely  two-way  flow  of 
information  among  key  elements  of  the  Division.  Individual 
information  updates  from  all  units  may  be  transmitted  two  ways 
via  tactical  communications  systems:  electronic  mail  and  data 
base  updates.  The  commander  may  have  the  data  displayed  in  a 
variety  of  formats  including  video  maps  with  graphic  overlays, 
pie  charts,  summaries,  situation  reports  ,  and  tables.  As  the 
commander's  decisions  are  made,  they  are  disseminated  to  units  as 
applicable  (Figure  3) . 


Figure  3  Flow  of  Information 


MCS  is  organized  to  provide  automation  from  Battalion 
through  Division.  In  support  of  this,  MCS  organization  within 
the  Division,  Major  Subordinate  Command  (MSC)  and  Battalion  is 
based  on  current  principles  calling  for  separation  of  the 
planning  and  directing  functions  when  fighting  battles.  This 
separation  is  accomplished  by  means  of  Command  Post  (CP) 
configurations  in  which  all  the  traditional  elements  are 
organized  and  physically  located  to  support  the  decision-making 
and  battle-making  process  (see  Figure  4) 

The  Division  CP  provides  the  facilities  and  interfaces 
which  allow  the  commander  to  see  and  direct  the  deep,  close-in, 
and  rear  battles,  allocate  resources,  plan  future  battles,  and 
position  combat  support.  The  Division  CP  is  composed  of  three 
echelons:  the  Tactical  Command  Post  (TAC  CP),  the  Main  Command 
Post  (MAIN  CP) ,  and  the  Rear  Command  Post  (REAR  CP) . 
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The  TAC  CP  is  the  hub  for  the  close-in  battle.  The  TAC  CP 
may  merge  with  the  MAIN  CP  and  provide  the  command  and  control 
function  for  the  MAIN  CP  when  no  forward  presence  is  required. 
The  TAC  CP  is  capable  of  sending  data  to  and  receiving  data  from 
the  other  echelons  of  the  Division  CP  and  MSCs 

The  MAIN  CP  provides  those  functions  essential  to  managing 
the  total  tactical  situation,  fighting  the  deep  battle,  and 
planning  the  future  battle.  The  MAIN  CP  is  the  hub  of  Command 
and  Control  within  the  Division.  It  is  organized  into  the 
following  elements:  G-3  Operations,  G-2  Operations,  G-3  Plans, 


and  the  Divisional  Airspace  Management  Element  (DAME) . 

The  REAR  CP  contains  those  elements  concerned  with 
sustaining  and  restructuring  the  force.  The  G-l  and  G-4  staffs 
are  located  here  along  with  the  Adjutant  General,  Judge  Advocate 
General,  Inspector  General,  Surgeon,  Chaplain,  and  those 
associated  with  combat  service  support.  It  also  has  the  same 
data  distribution  capability  as  the  MAIN  CP.  The  REAR  CP 
habitually  collocates  with  the  DISCOM  CP,  which  normally  provides 
command  and  control  for  the  rear  battle. 

Each  Major  Subordinate  Command  (MSC)  along  with  the 
Division  CPs,  is  capable  of  functioning  as  a  Division  Alternate 
Command  Post  (ALT  CP) .  This  capability  is  accomplished  by  means 
of  appropriate  communications  links  and  the  distributed  MCS  data 
base  common  to  the  echelons  of  the  Division  CP  and  the  other 
MSCs .  As  a  result,  MCS  provides  several  benefits.  First, 
information  essential  to  command  and  control  of  the  Division  is 
available  to  the  commander  at  whatever  CP  he  may  currently  be 
located.  Second,  only  minimum  essential  personnel  and  equipment 
augmentation  is  needed  to  allow  an  MSC  to  be  designated  as  an  ALT 
Division  CP.  Third,  as  the  tactical  situation  changes,  the  MSC 
designated  as  the  current  ALT  Division  CP  can  rapidly  and  easily 
be  changed.  Fourth,  since  all  MSCs  have  access  to  the  same  data 
base,  all  have  access  to  the  same  information  covering  the  entire 
battlefield  and,  thus,  share  a  common  view  of  it  (see  Figure  5) . 

Rounding  out  the  Division  and  MCS  are  the  battalion 
tactical  level  units.  These  Lower  Echelons  consist  of  Main 
Support,  Forward  Support,  Signal,  Engineer,  Combat  Support 
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Aviation,  Air  Cavalry  Squadron,  Air  Attack  Helicopter,  Maneuver, 
and  Field  Artillery  Battalions.  These  units  update  the  Upper 
Echelon  data  bases  with  the  most  current  information.  They  also 
support  the  Battalion  Commander's  command  and  control 
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requirements  and  his  decision  process.  Each  Lower  Echelon  node 
may  be  configured  either  as  a  single  workstation  or  as  several 
workstations  linked  together  in  a  Local  Area  Network  (LAN) . 

The  typical  single  workstation  is  based  on  one  portable 
computer.  Connected  to  it  are  a  printer  and  a  storage  device 
(either  a  hard  disk  system  or  a  floppy  disk  system) .  The 
computer  contains  pre-set  formats  for  records  or  reports  and  a 
mail  system  which  enables  the  user  to  send  information,  updates 
and  reports  to  other  nodes.  These  single  workstation  nodes  are 
usually  found  at  battalion-  and  brigade-  level  TAC  CPs,  field 
trains  and  selected  staff  sections. 

The  typical  multiple  workstation  nodes  have  several 
workstations  linked  in  a  LAN.  Multiple  workstations  communicate 
through  one  main  processing  unit  called  a  Server.  The  LAN  makes 
peripherals,  such  as  storage  devices  and  printers,  available  to 
all  users  on  the  network.  In  other  words,  the  LAN  offers  the 
following  benefits.  First,  it  allows  users  to  operate  without 
any  peripheral  equipment  at  their  own  workstation.  Second,  all 
users  on  the  network  can  have  access  to  the  system's  applications 
software  and  electronic  mail.  Third,  it  can  limit  the  access  of 
certain  individuals  to  specific  subjects  or  files.  Fourth,  the 
LAN  allows  users  to  store  their  programs  and  allow  others  that 
require  a  user's  information  to  have  access  to  it.  The  LAN 
configuration  is  usually  found  at  the  battalion-level  MAIN  CP. 

Central  to  the  LAN  is  the  Server.  It  controls 
communication  between  itself  and  the  peripheral  equipment 
attached  to  it,  communication  between  itself  and  the  portable 
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computers  attached  to  it  and  communications  among  its  internal 
processors.  All  user  activities  with  the  Server  take  place 
through  the  portable  computer.  As  many  as  48  of  these  computers 
may  be  supported  by  one  Server.  Information  may  be  stored  on 
hard  of  floppy  disk  systems. 

Communications  components  also  contribute  to  the  typical 
Lower  Echelon  hardware  configuration.  The  hardware  at  these 
nodes  is  capable  of  handling  several  means  of  communication  at 
one  time.  This  is  done  through  a  communications  interface  devise 
called  the  Data  Communications  Interface  Unit  II  (DCIU  II) .  The 
DCIU  II  is  actually  a  computer  that  can  process  information  as  it 
is  received  or  transmitted.  It  links  the  small  computer  with  any 
combination  of  up  to  three  single  FM  radios,  and  wire  lines.  It 
also  allows  information  to  be  received  on  several  channels 
simultaneously  without  losing  any  information  and  will  determine 
if  the  FM  radio  network  is  free  of  transmission  before  it  sends 
data.  3 

While  the  maneuver  control  system  is  an  aggressive  program, 
maximizing  the  use  of  commercial  off-the-shelf  hardware  and 
software  to  provide  an  integrated  command  and  control  system,  it 
does  have  three  major  shortcomings.  First,  ACCS  hardware  and 
software  systems  will  not  be  available  for  several  years. 

Second,  the  current  design  is  modeled  around  a  battalion  with 
collocated  companies,  restricting  UCLs  to  battalion  and  separate 
companies.  Third,  having  been  designed  around  a  maneuver  unit 
the  data  base  does  not  accommodate  the  magnitude  of  Engineer  data 
available  throughout  the  Corps  area. 


There  have  been  several  initiative  to  provide  a  near  term 
fix  for  these  problems.  The  United  States  Army  Europe  (USAREUR) 
has  recently  complete  a  scrub  of  their  battlefield  automation 
requirements  and  defined  a  structure  for  automation  within 
USAREUR  and  the  Seventh  Army  that  meshes  with  the  proposed  Army 
development  program.  It  provides  a  basis  for  defining  future 
automation  development  within  the  European  Theater. 

As  part  of  their  scrub,  they  have  defined  the  requirements 
for  a  USAREUR  Tactical  Command  and  Control  (UTACC)  system  that 
will  tie  together  the  USAREUR  major  commands  and  the  USAREUR 
Headquarters  and  provide  the  essential  automation  until 
implementation  of  the  Combat  Service  Support  Control  System 
(CSSCS)  and  the  Army  Command  and  Control  System  (ACCS)  in  the  mid 
nineties.  All  USAREUR  C2  initiative  have  been  rolled  into  this 
initiative  under  the  UTACC  label  to  reduce  proliferation  of 
hardware  systems  that  have  strained  logistics  and  training 
capabilities  in  the  past.  Acquisition  of  equipment  by  tactical 
units  is  limited  to  Army  standard  systems  or  their  approved 
surrogates.  USAREUR  will  define  the  standard  set  of  off-the- 
shelf  software  for  use  by  tactical  units. 

The  plan  to  overcome  hardware  shortfalls  over  the  next  four 
years  includes  using  standard  MS-DOS  micro  computers  for  the  Unit 
Level  Computer  (ULC)  and  TACCS.  The  plan  includes  battalion, 
separated  company  and  higher  peacetime  logistics  and 
administration  and,  on  a  limited  basis,  use  of  ULC  as  a  temporary 
filler  for  selected  ACCS  hardware  until  the  ACCS  systems  are 
defined  in  Fiscal  Year  88  and  89. 


To  insure  that  the  initiative  is  not  lost  when  the  real 
ULCs  are  fielded,  USAREUR  has  requested  Army  Material  Command 
assistance  in  quickly  developing  a  LAN  that  will  allow  the  ULC, 
the  ULC  surrogate  and  other  MS-DOS  systems  to  be  tied  initially 
to  the  Tactical  Control  Terminal  (TCT)  for  at  least  free  text 
messages  and  then  subsequently  into  the  TCP  for  full-up  netting. 
They  also  requested  the  software  necessary  to  link  the  ULC  to  the 
TCT  when  the  ULC  is  used  as  a  battalion  terminal. 

This  initiative  does  place  hardware  in  the  hand  of  the  user 
in  the  near  term,  however,  it  does  not  address  ULCs  below 
Battalion  level  nor  does  it  fully  exploit  information  available 
within  the  Engineer  community.  The  evolutionary  process  for  -> 
must  be  broadened  to  capture  knowledge  and  experience  gained  om 
attempts  to  develop  an  automated  command  and  control  system 
within  the  Engineer  community. 

Whether  under  the  current  Engineer  structure  or  the  future 
E-force  structure,  a  Division  commander  can  expect  to  see  up  to  9 
Engineer  Companies  in  support  of  his  area  of  operation.  That 
support  equates  to  approximately  9  platoons  or  27  squads  working 
independently  within  a  maneuver  brigade  sector.  This  dispersion 
of  engineers  throughout  the  division  area  provides  the  maneuver 
commander  with  a  unique  asset  to  analyze  and  report  critical 
terrain  data,  obstacle  data,  MSR  status,  and  river  data  as  well 
as  friendly  and  enemy  activity  across  the  division  front. 

The  engineer  structure  must  be  responsive;  on-site; 
integrated  with  the  maneuver  force  at  all  times;  ready, 
anticipating,  and  able  to  execute  the  commanders  concept  and 


requirements  throughout  the  battle.  *  However,  major 
shortcomings  exist  in  the  handling  of  the  large  amounts  of 
critical  terrain  and  obstacle  data  which  must  be  maintained  and 
analyzed  by  combat  engineers  and  disseminated  to  engineer  and 
maneuver  force  commanders  and  their  staffs  so  that  orders  may  be 
issued  regarding  future  execution  of  tasks. 

The  need  for  an  Engineer  Command  and  Control  System  (ECCS) 
is  dictated  by  this  requirement  to  handle  large  amounts  of  data 
and  the  combat  multiplier  effect  the  combat  engineers  provide  to 
the  maneuver  forces  in  the  areas  of  mobility,  counter-mobility, 
survivability  and  general  engineering.  The  current  manual  system 
for  acquiring  and  processing  critical  engineer  data  is  extremely 
tedious  and  time  consuming.  The  lack  of  accurate  and  timely 
processing  of  data  may  prevent  the  maneuver  commander  from 
reacting  inside  the  enemy's  decision  cycle  and  result  in  the 
unnecessary  loss  of  combat  personnel  and  weapons  systems. 
Commanders  and  their  staffs  require  processed  engineer 
information  to  plan  their  operations,  execute  those  plans  and 
modify  the  plans  during  execution.  Automated  systems  are 
essential  at  every  echelon,  from  engineer  platoon  to  Corps 
commander,  to  collect,  analyze,  and  report  critical  engineer 
information,  and  to  disseminate  it  in  a  timely  manner. 

The  ECCS  hardware  will  be  the  standard  hardware  fielded 
with  the  MCS  with  the  addition  of  a  hand  held  device,  configured 
for  the  platoon  leader  to  pass  information  and  receive  orders 
from  his  company  and  higher  headquarters.  The  software  extends 
beyond  the  scope  of  the  MCS.  It  includes  the  capabilities  for 
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engineer  brigades,  battalions,  companies  and  platoons  to  perform 
mission  related  computations  and  data  management.  The  software 
must  run  on  MCS  common  hardware  or  surrogate  hardware  as  is 
proposed  in  the  UTACC  system  for  USAREUR. 

The  equipment  to  run  the  software  must  include  a  source  of 
data  input,  equipment  to  store,  retrieve,  analyze,  and  report  the 
data,  and  the  ability  to  transmit  data  and  orders  to  higher  and 
lower  echelons  of  the  engineer  force  in  the  form  of  database 
updates  or  message  traffic.  The  equipment  must  tie  into  the  MCS 
so  that  ECCS  can  pass  pertinent  information  to  force  level 
commander  and  pull  required  information  from  that  or  other  nodes 
as  needed.  This  equipment  must  be  available  from  the  corps 
commander  all  the  way  down  to  the  engineer  platoon  leader.  The 
platoon  leader's  requirement  is  for  a  hand  held  device  configured 
to  allow  him/her  to  pass  information  and  receive  orders  from  the 
company  and  appropriate  higher  commanders.  All  other  engineer 
command  and  staff  elements,  from  the  company  up,  must  have 
hardware  that  will  permit  the  storage  and  manipulation  of  ever 
increasing  amounts  of  data.  These  same  organizations  must  also 
have  a  plotter  available  to  them  which  will  be  capable  of 
producing  overlays  of  obstacle  plans,  and  command  and  control 
graphics  on  map  size  sheets  of  acetate  and  paper. 

The  ECCS  software  must  provide  the  engineer  commander  and 
all  engineer  staff  elements  with  the  ability  to  track  the  status 
of  all  pertinenty  personnel,  equipment  and  resources.  The 
software  must  also  give  them  the  tools  to  analyze  this  data  and 
balance  it  against  various  taskings  in  the  form  of  engineer 
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estimates,  and  publish  OPORDERS  and  annexes.  The  software  must 
also  be  able  to  send  pertinent  information  to  force  level 
commanders,  either  as  database  updates  or  as  message  traffic. 

The  ECCS  software  must  be  compatible  with  standard  message 
formats,  the  Army  Command  and  Control  System  (ACCS)  and  the 
Maneuver  Control  System  (MCS) .  Only  those  portions  of  ECCS  data 
and  software  that  are  pertinent  to  the  force  level  commander  will 
be  resident  on  hardware  that  is  dedicated  for  use  by  the  maneuver 
commander.  The  full  compliment  of  engineer  technical  data  and 
engineer  unique  software  will  be  located  on  the  appropriate 
engineer  staff  officer's  hardware.  The  software  must  present 
menus  in  a  logical  order,  and  the  formats  must  be  in  a  manned 
that  allows  non-engineer  users  to  read  the  reports  and  messages 
without  the  use  of  a  decoding  aid.  The  transmittal  of  reports 
and  messages  must  be  simple  for  the  user,  flexible  enough  to 
modify  what  information  is  sent  to  whom  as  task  organizations 
change.  5 

The  feasibility  and  operational  capability  of  the  ECCS  has 
been  demonstrated  in  USAREUR.  The  Commander  of  the  7th  Engineer 
Brigade,  VII  U.S.  Corps,  initiated  a  program,  known  as  Automated 
Barrier  and  Terrain  Information  System  (ABATIS)  in  May  1984  to 
provide  timely  engineer  data  to  maneuver  commanders.  The  initial 
objective  was  to  field  a  system,  using  off-the-shelf  hardware  and 
software,  in  conjunction  with  existing  tactical  communication 
systems  to  provide  timely  engineer  information  for  maneuver 
planners  at  the  brigade,  division  and  corps  level. 


While  ABATIS  did  not  test  the  full  hardware  architecture 
from  platoon  to  corps  level,  it  did  demonstrate  that  the  near 
term  battlefield  automation  needs  of  USAREUR  can  be  met.  In 
addition  to  demonstrating  the  operational  capability,  tests  of 
the  system,  during  REFORGER  84  and  REFORGER  85,  provided  valuable 
insight  into  the  hardware  architecture  as  discussed  above. 

ABATIS  was  also  the  first  attempt  in  defining  the 
information  architecture  for  an  engineer  command  and  control 
system  in  USAREUR.  The  current  system  uses  IBM  compatible 
portable  computers  and  MS-DOS  software  to  track  enemy  order  of 
battle,  commander's  SITREP,  class  V,  friendly  and  enemy 
obstacles,  bridge  and  river  crossing  data  and  main  supply  route 
(MSR)  status. 

The  software  is  currently  being  updated  to  include  the 
capabilities  for  engineer  data  reports,  spot  reports,  and  mission 
and  barrier  reports.  The  commercial  software  procured  with  the 
system  also  provides  the  capability  for  word  processing,  database 
management,  and  the  preparation  of  spread  sheets  and  visual 
presentations . 

Concurrent  with  the  hardware  and  software  improvements  for 
ABATIS,  the  7th  Engineer  Brigade  has  initiated  a  thorough  study 


to  develop  an  information  architecture  to  standardize  all 
engineer  reports  within  the  VII  Corps.  While  designed  around  the 
data  entries  used  through  the  VII  Corps  engineer  units,  the 
architecture  has  direct  application  as  a  start  point  for  the 
evolving  Engineer  Command  and  Control  System.  The  information 
architecture  was  developed  using  the  format  prescribed  by  the  IBM 
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application  Manual.  The  architecture  is  a  tool  that  shows  the 
relationship  between  data  classes  and  military  command  processes. 

The  first  step  in  the  process  is  to  identify  all  data 
entries  used  within  the  target  community,  in  this  case  the 
engineer  units  within  the  VII  Corps.  A  data  entry  is  information 
of  lasting  interest  to  the  organization  and  is  categorized  as 
either  a  person,  place,  thing,  concept  or  event.  The  data 
entries  in  this  case  were  determined  to  be  the  information 
reported  by  engineer  units  to  their  higher  headquarters.  The 
entries  were  obtained  by  interviewing  separate  company  and 
battalion  commanders  and  their  staffs  of  engineer  units 
throughout  the  Corps,  and  analyzing  operational  reports  and  Field 
Standard  Operating  Procedures.  147  unique  and  distinct  data 
entries  were  identified. 

The  next  step  in  the  process  is  to  identify  data  classes. 

A  data  class  is  a  logical  grouping  of  data  related  to  things  of 
lasting  interest  and  available  for  decision  making.  The  147  data 
entries  were  broken  into  categories  based  on  the  type  of 
information  contained  in  each.  Eventually  14  different  data 
classes  were  identified.  These  data  classes  and  their 
definitions  are  listed  in  Figure  6. 

A  process  identification  matrix  was  used  (see  Figure  7)  to 
identify  the  military  command  process.  The  matrix  lists  the  life 
cycle  stages  of  a  mission  along  the  vertical  axis.  These  stages 
are:  (1)  Requirements:  Activities  that  determine  the  amount  of  a 
resource  and  number  of  missions  required,  (2)  Acquisition 
/Stewardship:  Activities  to  acquire  and  maintain  resources  and  to 


DATA  CLASS  DEFINITION 


Equipment  Type:  Tracked  vehicles,  wheeled  vehicles,  bridge 
parts,  construction  equipment,  special  equipment. 

Equipment  Status :  Amount  of  Equipment  on  hand,  amount  of 
equipment  authorized,  readiness  status. 

Mission  Type :  Mine  field,  point  obstacle,  tank  ditch, 
construction,  MSR  repair,  river  crossing,  assault  breach, 
reorganization  as  infantry,  reconnaissance. 

Mission  Status :  Planned,  executed,  percent  complete,  start  time, 
effective  time,  completion  time. 

Mission  Goal :  Mobility,  countermobility,  survivability. 

Unit  Type:  Combat  corps  engineer,  divisional  engineer,  bridge 
company,  heavy  equipment  section,  combat  support  equipment 
company . 

Enemy  Status:  Disposition,  unit  type,  type  of  enemy  obstacle 
emplaced,  estimated  breaching  time  of  enemy  obstacle. 

Material  Type:  Mines,  POL,  ammunition,  lumber,  sand,  gravel. 

Material  Status :  Amount  of  material  on  hand  at  unit  or  in  field 
stock  point. 

Material  Requirements :  Amount  of  material  required  to  accomplish 
mission. 

Personnel  Type:  Officer,  warrant  officer,  enlisted,  MOS  type. 

Personnel  Status :  Number  and  type  of  personnel  on  hand,  number 
and  type  authorized,  KIAs,  WIAs,  MIAs. 

Unit  Status :  Condition  of  unit  with  respect  to  morale,  location, 
equipment,  material  and  mission  load. 

MSR  Status :  MSR,  traf f icability ,  state  of  repair  and  capacity. 


Figure  6. 
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track  resources  and  missions,  and  (3)  Disposition:  Activities 
that  bring  resources  and  missions  to  the  end  user.  Basic 
resources;  product  (mission) ,  raw  materials,  facilities 
(equipment)  and  personnel  are  listed  along  the  horizontal  axis. 

Utilizing  the  process  identification  matrix  and  unit 
interviews,  18  military  command  processes  were  derived.  The 
processes  and  their  definitions  are  listed  in  Figure  8. 

The  next  step  was  to  develop  a  process/data  class  matrix. 
The  military  processes  were  listed  on  the  vertical  axis  and  the 
data  classes  were  listed  on  the  horizontal  axis  (Figure  9) .  A 
"C"  was  used  to  indicate  which  process  created  the  data  class. 
Each  data  class  can  be  created  by  one  and  only  one  process, 
although  it  may  be  used  by  many  processes.  Once  each  data  class 
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Develop  Overall  Strategy:  Determining  the  military  activities 
and  objectives  of  the  Corps  and  its  subordinate  units. 

Determine  Personnel  Requirements :  Determination  of  what  MOSs  and 
ranks  in  what  quantities  are  required  for  mission  accomplishment. 

Manage  Personnel :  Procurement  and  tracking  of  personnel  as  needs 
vary  to  battlefield  losses  and  changes  in  mission  requirements. 

Distribute  Personnel :  Distribute  personnel  to  units  as  required. 

Analyze  Battlefield:  Determining  what  has  occurred  and  is 
occurring  on  the  battlefield,  including  what  obstacles  are 
emplaced  and  being  emplaced. 

Analyze  Enemy :  Determining  enemy  activity,  disposition,  and 
probable  courses  of  action. 

Develop  Mission  Requirements :  Determine  what  missions  must  be 
accomplished  to  support  overall  strategy. 

Manage  Missions:  Prioritizing  and  evaluating  missions  as  they 
are  accomplished. 

Assign  Missions:  Assigning  missions  to  units  in  a  manner  that 
best  supports  the  overall  strategy. 

Determine  Equipment  Requirements:  Determine  what  equipment  types 
and  quantities  are  required. 

Manage  Equipment:  Procuring  and  tracking  equipment  as  needs  vary 
due  to  battlefield  losses  and  changes  in  mission  requirements. 

Distribute  Equipment:  Distribute  equipment  to  units  as  needed. 

Maintain  and  Use  Equipment :  Utilizing  and  maintaining  equipment 
in  the  course  of  mission  accomplishment. 

Determine  Material  Requirements:  Determine  what  materials  and 
quantities  are  required  to  support  the  overall  mission  strategy. 

Manage  Material :  Procuring  and  tracking  material  as  needs  vary 
due  to  consumption  and  changes  in  mission  requirements. 

Distribute  Material :  Distribute  material  to  units  as  required. 

Plan  MSR:  Determine  supply  routes  required  to  support  the  overall 
strategy. 


Manage  MSR:  Utilizing  and  maintaining  supply  routes  to  support. 

Figure  8.  Process  Definition 
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Figure  9  Process  Data  Class  Matrix 


had  its  creating  process  identified,  data  classes  used  by  other 
processes  were  identified.  The  "using  process"  is  identified  by 
a  "U". 

Groups  of  processes  were  then  identified  by  observing 
similar  patterns  of  data  usage.  Figure  10  shows  the  processes 
and  data  classes  broken  down  into  four  groups  based  on  data  usage 
patterns.  These  "process  groups"  can  be  identified  by  the 
processes  they  contain  as  operations  management  (S2  and  S3) , 
personnel  management  (SI) ,  equipment  management  (BMO)  and 
material  management  (S4). 
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Figure  10  Process  Groups 


Carrying  the  analysis  one  step  forward  it  is  observed  that 
whenever  data  created  by  one  process  group  is  used  by  another 
process  group,  information  must  flow  between  the  two  groups. 

Each  "U"  located  outside  a  box  represents  shared  information 
between  process  groups.  Figure  11  shows  the  information  flow 
between  process  groups,  known  as  the  information  architecture 
data  flow.  Removing  the  Cs  and  Us  and  rearranging  the  data 
classes  produces  the  Information  Architecture  Flow  Diagram 
(Figure  12) .  The  Information  Architecture  Flow  Diagram 
identifies  systems  that  form  the  overall  plan,  identifies  the 
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data  controlled  by  each  information  system,  identifies  the 
process  supported  by  each  system,  and  shows  the  flow  of 
information  between  the  information  systems. 
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Figure  11  information  Flow 


Commanders  and  Staffs  face  a  significant  challenge  as  the 
Army  moves  into  the  last  decade  of  the  Twentieth  Century.  The 
widening  of  the  battlefield  and  decrease  in  the  density  of 
combatants  which  has  marked  combat  operations  since  the  beginning 
of  this  century  have  made  it  more  and  more  difficult  for  the 
commander  to  "sense”  the  location  and  condition  of  his  forces. 
Likewise,  technological  developments  which  have  increased  the 
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Figure  12  Information  Architecture  Flow  Diagram 

battlefield  have  increased  the  pace  and  fluidity  of  combat;  and 
reduced  the  time  available  for  sensing  the  situation,  evaluating 
the  situation,  and  taking  actions  necessary  to  thwart  the  enemy 
intentions  and  win  the  battle. 

Our  most  likely  enemy's  forces  and  tactics  are  optimized  to 
maintain  rapid  movement  made  possibly  by  technological  advances. 
Our  response  to  this  threat,  the  Airland  Battle,  requires 
commanders  to  fight  a  wider,  faster  paced  battle  in  three  inter¬ 
related  areas.  The  commander  must  "see"  the  wider  battlefield, 
"sense"  the  enemy's  intention,  and  plan,  direct  and  coordinate 


actions  to  defeat  the  enemy  in  the  close,  deep  and  rear  Airland 
Battles.  The  staff  must  provide  the  commander  with  the 
information  necessary,  without  overwhelming  him  with  detail. 

Automated  Command  and  Control  Systems  need  to  capitalize  on 
the  same  technology  that  widened  the  battlefield  to  provide  the 
commander  and  his  staff  with  the  information  necessary  to  "see" 
and  "sense”  the  battlefield  and  provide  a  means  to  rapidly 
communicate  the  information  necessary  to  carry  out  the  commanders 
intention. 

There  have  been  many  initiatives,  formal  and  informal,  to 
develop  such  a  command  and  control  system.  The  evolutionary 
approach  to  development  of  the  Army  Command  and  Control  System  is 
a  positive  step  toward  fielding  a  system  that  takes  advantage  of 
the  availably  technology  and  incorporates  user  input  in  a  timely 
manner.  Informal  initiatives,  to  define  system  and  information 
architecture,  need  to  continue  in  order  to  place  systems  in  the 
field  now  and  provide  user  input  to  insure  that  an  effective 
Maneuver  Control  System  is  fielded  for  use  throughout  the  Army. 
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Engineer  Command  and  Control  System 
Engineer  Force 

International  Business  Machine 
Local  Area  Net 
Main  Command  Post 


MCS 


Maneuver  Control  System 


MI  BN 


MSC 

MSR 

MTF 

NDI 

PLRS 

REAR  CP 

REFORGER 

SITREP 

Sl/Gl 

S2/G2 

S3/G3 

S4/G4 

TAC  CP 

TCP 

TCT 

TCT ' 

ULC 

USAREUR 

UTACC 


Military  Intelligence  Battalion 

Major  Subordinate  Command 

Main  Supply  Route 

Message  Text  Format 

Non  Developmental  Item 

Position  Locating  and  Reporting  System 

Rear  Command  Post 

Return  of  Forces  to  Germany 

Situation  Report 

Personnel 

Intelligence 

Operations 

Logistics 

Tactical  Command  Post 

Tactical  Computer  Program 

Tactical  Computer  Terminal 

Tactical  Computer  Terminal  Prime 

Unit  Level  Computers 

United  States  Army  Europe 

USAREUR  Tactical  Command  and  Control 
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1.  J.B.  Carne,  Development  of  Operational  Requirements  for 
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2.  S.M.  Genensky  and  A.E.  Wessel,  Some  Thoughts  on  Developing 
Future  Command  and  Control  Systems.  Oct  1964,  pp.  1-11. 

3.  U.S.  Department  of  the  Army,  Maneuver  Control  System  Staff 
Users  Guide.  Oct  1986,  pp.  5-24. 

4.  U.S.  Army  Engineer  School,  Fort  Belvoir,  VA. ,  Briefing, 
E-Force  Army  of  Excellence.  Sep  1986 

5.  U.S.  Army  Engineer  School,  Fort  Belvoir,  VA.,  Operational  and 
Organizational  Plan  for  the  Engineer  Command  and  Control  System. 

6.  7th  Engineer  Brigade,  VII  U.S.  Corps,  Information  Management 
Study .  Dec  1986. 
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